The discovery that a computer system has been compromised can occur well after the occurrence of the compromising event. The delay between the event and the discovery of compromise can make identifying the compromising event difficult, as many other innocuous events may have occurred since the compromising event. Furthermore, systems may have experienced a compromising event but may appear unaffected. For example, attackers may not exploit every occurrence of a compromising event, or may not yet have exploited an occurrence of a compromising event. So many computer systems may have been exposed to a comprising event, but only some may show signs of having been compromised.
For example, a webserver may have been hijacked to inject malicious code into the web browsers of users visiting a webpage hosted by the webserver. But by the time the malicious code is detected, the user may have visited web pages hosted by many other webservers, making identification of the hijacked webserver difficult. Even a security service having access records for numerous users may have difficulty identifying the hijacked webserver, because the webserver may be programmed to attempt the attack randomly, or the attack may depend on a user behavior or equipment configuration that is only intermittently present. Thus the webserver may not inject the malicious code into the web browser of every user that visits the webpage. Similarly, the malicious code may not be triggered immediately. So a security service may not know which web browsers are uninfected and which are infected, but yet to be triggered.
As a similar example, an ATM skimmer may be configured to store the account information of users that perform transactions at the ATM account. A criminal may later use this stored account information to perform unauthorized transactions. But during the time between the skimming of the account information and the unauthorized access, a user may visit several ATMs. Likewise the criminal may only perform unauthorized transactions in some of the accounts for which the ATM skimmer stored account information. As in the prior example, these factors may make it difficult to determine which ATM is compromised by a skimmer.
As another example, an unscrupulous merchant or employees of the merchant may acquire credit card information from customers during transactions that occur with the merchant. The acquired credit card information may later be used for unauthorized purchases. Given the delay between the unauthorized acquisition of credit card information and subsequent unauthorized purchases, it can be difficult to determine when the theft occurred and by whom. Many transactions with other merchants may precede the unauthorized use. Moreover, only a subset of the stolen credit card accounts may be subject to unauthorized purchases.
As shown in the above examples, a method for detecting events that compromise resources is provided. In a general case, it is desirable to determine a resource that is responsible for a given event. For example, when accounts are breached, it may be desirable to determine a database at which the breach occurred. As still another example, when financial account information is stolen and used without authorization, it may be desirable to determine a merchant or an automated teller machine (ATM) from which financial account information was skimmed or otherwise intercepted.
However, large-scale storage and exchange of electronic data poses a unique challenge for isolating resources that are responsible for events. In many cases, it is straightforward to determine a physical resource that is responsible for an event that affects physical actors. For example, a physical merchant is likely responsible for check fraud conducted using a physical check provided to the merchant. But with the advent of storage and exchange of electronic data, including the transmission of electronic data over networks such as the Internet, isolation of resources becomes more complex. An account found to have been breached may have been accessed through any number of channels. These channels may include one or more databases, financial institutions, and merchants, as well as any communication path between them. Therefore isolating where a security breach occurred among many electronic transactions has become very difficult. Moreover, monitoring large data sets in real-time provides unique problems.
Due to the continuous and complex exchange of electronic data in modern transactions, conventional systems may be unable to isolate specific resources in real-time in order to determine whether one resource over another is responsible for an event. By the time an event is detected, electronic data may have reached any number of resources, many of which may be separated in time and/or in geography from the event and/or from an affected actor (e.g., an account, a customer, and/or a financial card). Conventional systems may therefore be unable to determine the resource responsible for the event.